SSOCs have changed ASIC development teams to ASIC integrator teams. An ASIC integrator team's prime responsibility is the verification of the SSOC to test for functionality and manufacturability, and to interface with the fabless supplier in order to take the SSOC ASIC to production. Traditional ASIC development teams — working at the gate level — now mostly develop IP or validate IP from a supplier. This means that new ASIC/IP development teams need to have a flexible design environment, and must be able to add IP from different vendors and test it even before the IP is purchased.

To ensure the decisions on IP selection and integrations are technically sound, ASIC/IP teams commonly designate an engineer dedicated to IP analysis and procurement issues. This engineer is someone with deep knowledge of ASIC design processes, who knows the issues from verification to siliconization. One responsibility of this person is to grade the IP, to get a good idea of its quality and reliability. For contract development and final negotiation, someone from procurement is essential to make sure that all terms and conditions are as expected.

The design cycles for SSOCs are the same as those of traditional SoC designs. However, ASIC part volumes have increased significantly as functions from multiple ASICs are integrated into SSOCs commonly targeted for multiple products. This makes first-time success, time-to-market, yield issues and design-for-yield and design-for-manufacturing extremely important goals. Thus, especially with the advent of 90-nanometer technology, utilizing siliconized IP becomes very important.

But all siliconized IP is not equal. Active monitoring of the IP providers throughout the IP's design cycle is a necessity. Since a design engagement usually starts at the verification stage, well before the IP is siliconized and tested, loopbacks are essential to make sure that siliconized IP functionality is the same as intended functionality. There is always the possibility that someone modified the functionality just slightly, thinking it wouldn't cause problems — an assumption that results in major functionality issues later on.

It is also important to fully validate IP, even if it has been siliconized and used in other applications. Earlier applications may not have exercised all the functions in the IP. It could happen that a new application may invoke an instruction or command that was not tested properly or was never used before.

Typically, there are five sources for obtaining IP: partner company, fabless-driven IP, vendor IP, internal IP design or outsourced IP design. SSOC designers may be using any combination of these on a particular design.

Generally, the easiest model to use, and the one with least overhead, is the partner company model. It involves a highly trusted relationship where exact road maps are passed between the companies. The partner then designs or obtains IP from its sources based on the customer road map. The partner company is responsible for making the IP work and delivering it to the SSOC design group.

This model works well if the SSOC design company and the partner supplier's design focuses match. However, one limitation is in cases when the partner company may not have the desired IP in its portfolio and, in fact, the IP may not be in the road map of its other customers. This generally creates resistance from the partner and demands for additional funds.

In the case of the fabless-driven IP model, the customer has the freedom to choose the right fabless company, allowing for better focus in the areas of interest. A fabless provider in the imaging area will be best for imaging products, for example, while one in networking will be best for providing that type of IP. The specialization of fabless companies gives them an edge in providing solutions better suited to satisfying the customer. The fabless company takes the IP through siliconization and guarantees its workings.

Vendor IP is used typically where the above two models do not provide IP, or when IP must be used across multiple partners or fabless suppliers. Also, IP that needs to be verified early on in the SSOC may be available only at IP vendors. The first step is to get the simulation models and integrate them into the design. Many IP vendors prove their IP using shuttles or test tracks provided by foundries. For companies doing a customer-owned-tooling design model, this is one of the main methods of acquiring IP.

To differentiate and personalize products, differentiation IP is commonly designed by internal groups. This can be an important aspect of the design and actually may be the reason for doing the SSOC in the first place. However, this is one area that generally gets less attention or IP structuring than it should.

The integration success of internal IP depends on the design company's ability to structure and package the IP in the same way it gets IP from others. It is important to make sure the internal IP is well-documented and released in the same way as one would expect of external IP. Like external IP, the internal type is also a source of bugs and is often revisited to clear them.

Outsourced IP is a way to use lower-cost design resources to develop IP but still maintain control on the IP and structure it in a way to make the integration easier. Typically, the ASIC/IP group's design methodology is transferred to the design house and the resources are used as an extension of the internal ASIC IP development team.

Call for documentation
A typical SSOC will have IP from multiple sources. This makes the job of the IP integration team very difficult. Different silos have to be created to validate the IP, which takes a lot of the designers' time. It is important for a company to make its methodology known very early on to its partners. This includes documenting the methodology in book form and covering all aspects essential for verifying the design. One of the issues hindering rapid IP development, and increasing the cost of integration, is the multiplicity of internal design packages. These situations not only take time to sort out, but also make the process error-prone. Risks include slipped time lines and malfunctioning IP.

The figure shows multiple levels indicating costs incurred because of the time and effort needed to obtain and validate IP (indicated by the width of the levels). The widths will depend on the efficiency of the SSOC or ASIC/IP groups. Inefficient groups will have wider bands, making the external IP integration more difficult. External IP may be cheap. But the cost involved in validating and integrating the IP may not make it a viable option.

SSOC generation will become more and more feasible as proper interfaces are developed to allow IP to be incorporated in designs. HP is actively pursuing standards, like those from the Virtual Socket Interface Alliance, to allow IP packaging and encapsulation options, which decrease the time needed to set up IP for validation and integration. Standardization is especially urgent for companies that have products in multiple areas and need IP across a wider functionality space.

Currently, the effort needed to develop SSOCs has resulted in larger-than-desired teams, and the deriving of ASSP solutions to justify the time and effort needed for a particular SSOC. With a standardized IP distribution and integration system, product companies will be able to get over the initial validation and subsequent integration issues much more easily. This in turn will allow them to concentrate on their own differentiation IP, drive innovation and create better end-user targeted products.

Mobashar Yazdani is an ASIC program manager at Hewlett-Packard Co.'s Global Operations (Palo Alto, Calif.). Mike Stahl is an alliance manager/design technology scientist at HP's Hardware Systems and Technology Division (Fort Collins, Colo.).

Copyright 2005 © CMP Media LLC